Hello everyone, I am very happy to be able to share with you some of the research results we have done in the Middle East.
First of all, let me introduce myself. My name is Xingxin Yu. I am the first person in front of the fight number.
And there is Jimmy Su, who is also working on this research together with me.
He may also be at the scene, or he may be on the plane.
We are from the U.S. Gui Gu Institute of Research in the Middle East.
Our main research is secondary intelligence analysis.
In this talk, we mainly want to share with you how to use automation to better analyze software loopholes,
and better find the fundamental reasons for these software loopholes.
I believe everyone here may have written a program.
Of course, some of you may be more interested in security, but you have never written a program.
I believe some of you may have written a program.
I believe if you have written a program, you must have encountered a lot of various problems.
For example, no matter how much time you spend,
even when you go to school,
your teacher left you a homework saying that you will go back today to write a simple program.
I believe you must have the feeling of debugging.
It is impossible for you to write this software once and it will work.
In most cases, you may have written it many, many times, and you will find that this bug is constantly existing.
Then you will find a way to debug it and finally make this software work.
So for a small program like this, for a large program,
you can think of a program like Office, or even a program like the operating system.
This bug is unavoidable.
And in order to eliminate these bugs,
of course, companies, companies, software developers,
often spend a lot of manpower and material to do various tests before releasing software.
The ultimate goal is to ensure that the software is as stable as possible after it is released.
But unfortunately, no matter how much effort you have spent,
how much time you have spent, how much money you have spent,
in the end, your software will not work.
There will be a lot of problems like this or that.
And when these problems are triggered,
it will often lead to very serious consequences.
For example, in the simplest case,
when a bug is triggered,
our software will no longer work.
This will lead to a very bad user experience.
In addition, this is not a big problem for many people.
The worst case scenario is to restart the machine, right?
Or turn off the software and restart it again.
You will find that it may work normally.
If you think this is not a problem,
then I can tell you,
I believe that everyone here
is very interested in security.
So when there are some bugs,
they may even be used by hackers.
In this case, a specific attack can be achieved.
If there is such a bug,
it may be more harmful to you.
So in the real world,
in order to analyze bugs,
there are many methods that have been proposed.
For example, the simplest way is
when you find a bug,
if you use Windows,
it may pop up a window.
Now you can put your crash,
the crash of the software,
return it to Windows,
return it to Microsoft.
Microsoft can analyze it there.
Or you will see that there is a link search method,
and so on.
But unfortunately,
even if you return such a bug to the end,
under many circumstances,
analyzing this bug
will often take a very long time.
Because a simple crash
often does not give you too much information.
So today,
what I want to share with you is
in history,
how do you debug in a company?
How do you debug in a company?
And what is the best way
to achieve this kind of work?
I think I have already talked about this slide.
We can skip it directly.
In order to help the debugging of software,
there are two main methods.
The most common one is called
Recall Replay.
The so-called Recall Replay
means that when you find a bug,
sorry,
when you run the software,
you constantly monitor
and track the entire implementation process of the software.
You record every command that has been executed,
and every change in the memory.
Then you think about it.
You record every time
the events that happened in the program.
When the program is wrong,
the simplest way is that
you can replay every action just now.
In this way,
you can find the fundamental problem
of the software
better and faster.
However,
the biggest problem of such a resolution program
is that
you will pay a lot of calculation costs.
Because in the process of your program operation,
you monitor every command execution,
record any many commands,
record every memory operation.
In this way,
you will imagine
that your operation time
may be one second.
There may be tens of thousands of commands
that have been executed.
And if you want to record a 10-minute,
the situation in the past 10 minutes,
you may not have enough hard drives,
or even you do not have enough resources
to complete this task.
So,
although record-replay is good,
it is beautiful,
but in the real world,
no one really uses it.
So,
for such a problem,
the vast majority of enterprises,
including
the vast majority of enterprises,
even in many experimental environments,
such record-replay methods
are generally not used.
So,
in addition to record-replay,
another method
is also a traditional method
to realize debug.
This is called
log analysis method.
So,
log analysis method means that
if my program suddenly collapses,
if I suddenly make a mistake,
then I will make a fast record
of the current memory
in this state of error,
and also make a fast record
of the current memory value,
and then send all these information
to software developers
to let them do the diagnosis.
One advantage of this is that
you can know very clearly
what the current memory state is like
when the program has a problem,
the current memory state
is in what kind of situation.
So,
with such information,
it can often help you
to better complete the debug.
But this also brings
a problem.
Because in this case,
you only have
a current memory state,
and you don't have
the entire program
running in the past
for a period of time.
So,
your information
will be very, very little.
So,
the problem with very little information
is that
when you are debugging,
you have to do a lot of reasoning,
do a lot of guessing,
and even you may
make a mistake
in reasoning
or guess wrongly,
which makes it difficult for you
to find the fundamental cause
of the software error.
So,
you can see
in this table,
we summed up
the method of record-replay
is very good.
But its disadvantage
is that
its efficiency is not high.
So,
for this kind of
ordinary log method,
for example,
this kind of
core dump analysis method,
it is lightweight
because you no longer need
to monitor this program.
The operating system
can quickly
collect the core dump
for you.
But its disadvantage
is that
its efficiency
may be very poor.
So,
in order to solve
such a problem,
in order to solve
such a problem,
in the past,
in Jindong,
Meiyan,
in the past
three years,
we have done
a lot of such work.
Our goal
is to
help our developers
to analyze
the fundamental cause
of the software error
faster and better.
From 2016
to 2019,
this is
what we have done
in Jindong,
Meiyan.
So,
what I want
to share
with you
today
is
the second
and third
work.
Simply
speaking,
our first work
is to
make a program
code
as an input.
At the same time,
we use the core dump
as an input
for its memory
when the program
Then,
we perform
various analysis
to automatically
find the root cause.
Today,
we will not
share this method
with you.
We want to share
the second and third
with you.
So,
what are its advantages?
The second method
is that
when the program
collapses,
we can quickly
get such a core dump.
At the same time,
we can also use
some of the features
of the existing hardware
to collect
some of the
traces of the program.
I will show you later.
Then,
through reverse execution,
we can find
the starting point
of the program.
Later,
I will show you
how this tool
works.
This tool
is called
PUMP.
But,
in the following
talk,
I can also tell you
why this method
is sometimes
very difficult
in the process
of using
in our companies.
Recently,
how do we use
AI technology
to improve
such analysis methods?
Before I talk about
how to do analysis,
I would like to
introduce you
some background knowledge.
I have already mentioned
the so-called
program analysis.
When the program
collapses,
the network operation system
will make a quick photo
for the program.
In this quick photo,
there is often
an internal storage state
of the program.
At the same time,
there is also
the current storage state
of the program.
The combination of these things
is called
Core Dump.
Basically,
all operating systems
now can provide
such capabilities.
As long as the program
collapses,
we can get
the internal storage state
of the program
that we can see
at the collapse point
and its value
But,
I just mentioned
that the information
in a Core Dump
is very limited.
It only has
some information
because you only know
the internal storage state
when it crashes.
You don't know
the internal storage state
of any point
before it crashes.
So,
its information
is very limited.
So,
it is very difficult
with just Core Dump.
But,
recently,
Intel has
released
a new hardware feature.
It should be
from i7 processor
that all Intel processors
provide
this
processor trace
function.
What is
the processor trace?
When the program
is running,
the CPU
can record
you have executed
in the past
at the lowest cost.
Then,
when the program
crashes,
it can record
all the commands
you have executed
including the current
internal storage state
when the program
and put them
in the Core Dump.
So,
there is an advantage
in doing this.
What is the advantage?
Apart from knowing
the internal storage state
when the program
you can also
quickly understand
the command
executed
before the program
So,
with this command,
including
the internal storage state
when the program
your analysis
will become
relatively simple.
Please pay attention
to my error.
What I am saying
is relatively simple.
It is not
very,
very simple.
Later,
we will see
what is the reason.
So,
in our work,
we take
the method
that we want
to use
Core Dump,
that is,
we can find
the error point
of the program
So,
in the following
talk,
I will share
with you
step by step
how we
do this work.
So,
before I start,
let's take a look
at a simple program.
This program
is very,
very simple.
So,
in this program,
you will find
that it crashes.
It makes a mistake
in the 19th line.
In the 19th line,
it makes a mistake.
If you are
given the wrong program
and you are
asked to do
a diagnosis,
how do you
do the diagnosis?
You will find that
R is a pointer.
This pointer
is transmitted
through this function 3.
Then,
we can see
step by step
who used
3?
It was used
by function 2.
In function 2,
this pointer R
is multiplied
in function 2.
Then,
if we
analyze it further,
we can easily
analyze it
step by step.
We will find that
in function 1,
actually,
this R
is transmitted
from the 8th line.
So,
this is a non-pointer
dereference.
Then,
you will find that
in the debug process
just now,
we move
each sentence
backwards
step by step.
In fact,
this gives us
an idea.
What is it?
When we get
a program,
the memory state
of the error
every instruction
it performed before,
we can take out
the instruction series
first.
Then,
for the
CRUSH point,
this instruction
starts
to be executed
one by one.
Then,
in this process,
we can restore
its data flow.
Then,
according to this data flow,
we go back
step by step
until we find
the specific instruction
for the real
So,
I mentioned
reverse execution just now.
Then,
you will think
that since
reverse execution
looks very
You already have
all the order series.
Then,
I will execute
each order
one by one.
It seems to be
like this.
For example,
you can see
some simple examples
here.
For example,
add
eax10.
Then,
it actually
operates
the memory
eax10.
Then,
the easiest way
this instruction
is to
reduce
eax10.
Then,
the reverse function
of this instruction
can be found immediately.
Similarly,
for sub eax216,
you can reverse it.
You can just
add eax216
when you reverse it.
The first eax is the same.
You can also
add eax1.
Increase eax.
You can do
eax-1 accordingly.
It looks very,
very simple.
We can
reverse
each instruction
step by step
and operate it.
But in fact,
it is not like this.
Because there are
many, many instructions
that cannot be reversed.
For example,
this one.
For XOR
eax,
what it does
is to
clear
eax.
Then,
once this instruction
is finished,
you have no way
to know
how much
this instruction
is executed.
Because this instruction
cannot be reversed.
Similarly,
for the above example,
move eax5,
in fact,
this instruction
is also not reversed.
You don't know
how much
you can assign
eax to this 5.
Before that,
you don't know
how much eax
is equal to.
You don't know
how much eax
You don't know
how to reverse
this instruction.
So, what do we do?
There is a good way.
That is,
we can use
data flow analysis
to guess
the specific
of each instruction
before it is executed.
Let's look at
a simple example.
Here,
we have
five instructions.
Very simple
five instructions.
So,
if
the five instructions
are executed
in the fifth instruction,
this instruction
is crushed.
When it is crushed,
we have
a core dump.
We have
an internal memory
speed.
This speed
grows
like
the table
on our right hand side.
Its value
is inside.
So,
in addition to
the internal memory speed,
we also have
the value of the memory.
With
such a core dump,
with such a
collection sequence,
how do we
go back step by step?
First,
let's look at
the fifth instruction.
This is the
crush point.
So,
what we need to do
is to go up
from the last one.
Here,
we know
the value of
EX and EBX.
After executing
this instruction,
its value
is displayed
in the table.
If we use
data flow analysis,
our goal now
is to know
how much
EBX is
equal to
before executing
the fifth instruction.
A good way
is to
find out
how much EBX
is equal to
before executing
the first instruction.
The first instruction
and EBX
are equal.
When the fifth instruction
is executed,
the EBX
is repeated.
So,
we can quickly
deduce that
the EBX
is equal to
the EDX
before executing
In other words,
the EBX
and the EDX
must be equal
before execution.
So,
this is easy to do.
For this instruction,
we can take
the value
of EDX
and
add it to EBX.
In this way,
we can move
the entire
program counter
up.
In this way,
I have restored
the value
in the previous state.
It looks simple.
Let's go down.
Now,
what we want to do
is to execute
the fourth instruction
in a simple reverse direction.
We can use
the same method.
We want to know
how much
ECX value
is equal to
when executing
the fourth instruction.
So,
we can see
that
if you are familiar
with this,
you may know
that
when I see
the second instruction,
ECX is multiplied.
Its multiplication
is from
the memory
the EDI
to
the ECX.
The ECX
can be transmitted
to the fourth instruction.
So,
you may
conclude
that
before executing
the fourth instruction,
the ECX
is actually
equal to
the value
in the memory
of the second instruction.
So,
if you think
that
the EDI
is now
45,
you can find
the corresponding
memory
of 45.
You take out
the value
of 22
and
give the value
to ECX.
You can do this.
Is there a problem
in doing this?
It seems
that there is
no problem
in doing this.
But I want to tell you
that
doing this
will actually
make a mistake.
Why?
Let me
give you
another example.
Before
executing
the third instruction,
we can
assume that
the ECX value
is equal to
the value
in the memory
of the EDI.
Let's assume
that
the value
in the memory
of the ECX
in the third instruction
and
the value
of the EDI
are not
the same
in the memory
of the EDI.
In other words,
these two
indexes
are not
the same
in the memory
of the EDI.
If they are not
the same
in the memory
of the EDI,
of course,
we can boldly say
that before
the execution
of the fourth instruction,
the value
in the memory
should be
equal to
the value
in the memory
of the EDI.
But if
they are
the same
in the memory
of the EDI,
the situation
will be
completely
the opposite.
Let's see
why this is the case.
If the EDI
is equal to
the ECX,
that is,
before the execution
of L4,
the EDI and
the ECX
are the same
in the memory
of the EDI,
then we can
infer that
the ECX
should be
equal to
the EDI.
Therefore,
we can
analyze
the second instruction
and
the value
in the memory
of the ECX
cannot be
transmitted directly
to the fourth instruction.
Therefore,
we should
give the value
of 45
to the ECX
instead of
giving the value
of 22
in the memory
of the EDI
to the ECX.
I don't know
if you understand
what I mean.
If the EDI
is equal to
the ECX,
then the value
of the ECX
should be
equal to
the value
of the EDI,
which is 45,
not 22.
So,
in the real world,
how can we know
whether
the EDI
and
the ECX
are the same
in the memory
of the EDI?
This is
a very
difficult
question.
In order
to solve
this problem,
we used
an assumption
test.
The assumption
test is
very simple.
We first
do two assumptions.
When we are not sure
whether they are
the same EDI
or
the same memory
address,
we first
make two assumptions.
The first assumption
is that
the two memory
uses
are not
the same
address.
The second assumption
is that
they are
the same
address.
Then,
based on
these two assumptions,
we do
data analysis
and infer
the corresponding
limit
through
the limit
to determine
which assumption
is true
and which assumption
is false.
Let's use
this example
to explain
how to
solve
this problem.
The first
example is
the EDI
and
the ECX
are the
same
address.
The other
assumption
is that
they are
not
the same
address.
With this
assumption,
we can
construct
the use-defend
chain.
Because this is
a combination
instructions,
we can
use
and define
these two
boxes
to describe
the first
For the second
instruction,
we can also
describe it
these three
blue
boxes.
Then,
we can also
define
the use-defend
chain
in the
use-defend
chain.
The first
assumption
is that
the two
memory
addresses
indicated
by
ECX
and EDI
are not
the same
address.
So,
we know
that
the use-defend
chain
of
this
always
be
transmitted
to
the end
of this
use-defend
chain.
So,
we can get
this combination.
That is,
we can know that
in the fourth instruction,
ECX
should not be equal
to EDI.
ECX
should be equal to
the value of
the memory
indicated
Then,
the memory indicated
by ECX
should be equal
to ESI.
We can get
such a
constraint
combination.
Then,
we have two
different
constraints
combinations.
The first
ECX
should be
equal to
the value
by
EDI.
The second
constraint
ECX
should be
equal
to
the value
indicated
by EDI.
That is,
structures
are
equal to
the value
indicated
by
ECX.
Let us
test
Our test is very simple.
Let's verify it.
First, we see that ECX is equal to the internal storage value indicated by EDI.
Currently, we see that the internal storage indicated by EDI should be 45,
which is the internal storage indicated by 45.
Then we can take out the value, which is equal to 22.
We restore 22 to ECX,
which means that ECX should be equal to 22 at this time.
No problem.
Go on.
Second, ECX should not be equal to EDI.
At this time, we see that ECX is equal to 22.
Now, EDI should be equal to 45.
So, they are not equal.
No problem.
It is also satisfactory.
Then we look at the third condition.
The third condition is that the internal storage indicated by ECX should not be equal to ESI.
ECX's internal storage is now 22.
So, its value is 18 at the position of 22.
So, ESI's value is 22 now.
So, we can quickly know that this set of assumptions
is not satisfied with this condition.
So, we can quickly reject this set of assumptions.
Since this set of assumptions is wrong,
I think we don't need to verify the second set.
Because one set is wrong,
the other set is definitely right.
So, we can quickly know through this method that
the two internal storage EDI and ECX
are actually equal to each other before executing the fourth command.
So, through this method, we can know this thing.
So, after having such an ability,
we can quickly
perform the reverse execution of each command in this example.
So, at the same time, we can restore the internal storage state.
What is the advantage of this?
We have the internal storage state.
We have the internal storage state of each command before and after execution.
In the process of debugging,
we can use an automated tool completely.
The existing automated tool can find the root cost of this software completely.
That is to say, if a program collapses,
you can find its fundamental cause directly.
The fundamental cause of its collapse is very easy to find.
So, just now, I talked about this.
So, our assumption test looks very good.
But in fact, it still has a lot of problems.
Here, I can share with you the main problem.
So, the first problem is
I just mentioned it.
In order to get all the command series,
all the command series executed before,
we use the hardware feature of Intel PT.
Intel PT by default does not record the commands executed in the system debugging.
So, you can imagine that a user-oriented program will have system debugging.
It will interact with the system debugging.
When this happens,
we can't, by default,
we can't record the commands executed by the system debugging at that time.
So, this is the first flaw.
The second flaw is
when we do data flow analysis,
this is the first flaw.
The second flaw is
just now, our algorithm did an assumption analysis.
So, you can think of an example like this.
If I want to judge whether memory 1 and memory 2 are correct,
but I want to judge whether they are not,
the premise is that I have to know
whether memory 3 and memory 4 are correct.
Then, you can imagine that
if we need to judge whether memory 3 and memory 4 are correct,
but we need to judge whether memory 5 and memory 6 are correct,
then you can imagine that
our algorithm may increase the index level.
For example,
we need to judge whether memory 1 and memory 2 are correct.
We may have to judge whether memory 3 and 4 are correct.
we can first determine if 3 and 4 are transparent indexes.
After that, we will continue to execute on the other side.
You can imagine that if we have a lot of internal memory visits like this,
and we all need to do a transparent index test,
then the complexity of this algorithm should be N O N m square.
If m equals 2, it may be fine.
n to the second square may be fine.
But if m equals 5, 6, or 100,
it may be very difficult to deal with.
Such an algorithm cannot be used in the industrial world.
Therefore, in JD, we strongly demand that m must be equal to 2.
I can force m to be equal to 2,
but m equals 2 is still reasonable.
But the problem is that you may not be able to find the correct answer
to the fundamental reason for the actual end of the program.
Let's see if this is really the case.
We have a problem.
We did a simple experiment.
This is some CVEs that we collected in JD.
You can see that the characters in the CVEs may be a little small.
But to summarize,
the vast majority of CVEs may be stack overflow,
and some heap overflow,
and some formal output,
and some non-pointer dereference,
and use-after-free and invalid-free.
We used these 31 CVEs to trigger the problematic software
and get the corresponding CRUSH dump.
After we get the CRUSH dump,
we will use the methods we just mentioned
to use our tools to do the diagnosis.
We can skip to this page.
We want to show you our results.
This table lists some interesting things.
The first thing you can see is that
because our goal is to do reverse execution,
and then we find every instruction that leads to this CRUSH fundamental reason.
So through our method,
we want to see if we have overtinted.
Because we have back-overtinted to find the real root cause.
We want to see how much we have overtinted.
You will see that in this table,
we do have some overtint,
which means we have found some extra instructions.
But this overtint has very little impact on us.
In the vast majority of cases,
for example,
GROUND TRUTHS needs to be tinted to 6 instructions.
Our tools will only tint to 29 instructions.
29 instructions is actually a very small number,
because compared to all the TRUTHS on the left side,
this number,
you may need to analyze more than 3,000 instructions to find the root cause.
Through this method,
you may only need to look at 29 instructions,
and you can find the root cause.
So in general,
this effect is still okay.
Let's look at the second one.
The second one is,
I have already talked about this,
the number of analysis does not need to be too much.
The third observation is that
when this appears,
can we actually find the real root cause?
Can we actually find the real root cause
of this CRUSH instruction?
When we look at the 31 CVEs,
there are only two CVEs
that we cannot successfully find the root cause.
Let's take a look at the reason.
For the first one,
the reason is,
as I have already mentioned,
because of the process of tracking the program execution of the Intel PT,
it will not track all the instructions in the system call.
Because of the loss of these instructions,
we cannot succeed in some cases.
So this CVE20148322,
this specific CVE,
we cannot deal with it.
Let's look at the next one.
The next one,
the CVE20062971,
we cannot deal with it.
This is a整形溢出.
We cannot deal with a整形溢出
because of the following reason.
Because of the整形溢出,
it will lead to a loop.
It will continue to execute all the instructions in this loop.
You can imagine that
Intel PT will store all the instructions
in a looping loop.
When the loop is full,
it will rewrite it.
When there is a loop,
all the instructions in the loop will be included in the looping loop.
That is to say,
the instructions that lead to the error of the program
are not in the looping loop at all.
So this is the reason why we failed.
But in general,
there are only two out of 31 that cannot be done.
So in general,
it's not bad.
After we finished our tool,
we opened it up.
After opening it up,
Microsoft has a set of tools.
They also saw us.
Their development team also saw this tool.
They went back and tried it.
And they also asked us a question.
You can see in this table,
when we use our tools to deal with this,
this is not a CVE,
but it is a Stack Overflow.
To deal with such a specific example,
in order to find the root cause of the error,
our tool took six hours.
After Microsoft took it back and ran our tool,
it ran in all kinds of crashes.
It also found that
in many cases,
our tool may take two days
to find the real root cause
of the error in the software.
So Microsoft had an interaction with us.
They asked us,
why does this tool take so long?
This is unacceptable in the industrial world.
Because in the data center,
especially in IBM,
including Microsoft,
in their data center,
the error in the software is very common.
There may be thousands of such software errors every day.
So with our tool,
you can think about it.
There are thousands of them every day.
If it takes an average of six hours to deal with one,
you basically need a lot of machines
to do the calculation at the same time.
If it takes two days to deal with one,
you may have a lot of crashes
that you don't have time to analyze.
So this tool,
in industrial products,
when we launch it,
although it's not bad in our test,
but when we push it
to the real industrial product,
we find that it actually
doesn't really solve the problem.
The main reason is that
its efficiency is too low.
So after we thought about this problem,
we wanted to solve this problem.
So this year,
from the end of last year
to the beginning of this year,
we wanted to solve this problem.
But the method we took
was to use AI technology.
I won't give you too many introductions here.
If you're interested,
we can sit together
after this talk,
and we can continue to discuss.
So I'll just give you some
simple high-level ideas.
On the left,
it's command training.
In many cases,
when we do reverse execution,
as I just mentioned,
we want to know
if the two memory cells
are the same name.
Right?
We want to do analysis
of the same name index.
So in many cases,
we have to do
the hypothesis test
that has a very high
computation cost.
That is to say,
the assumption test.
So it takes a lot of time.
If I can use AI technology
to make a quick judgment,
for example,
I use AI technology
to divide the memory first.
For example,
I divide it into different
memory blocks.
Then I use AI technology
to predict
which memory block
belongs to which
specific block
in each command.
If deep learning
can accomplish
this kind of work,
then I can do
a very...
I don't need to
do the hypothesis test anymore.
Why?
Because you can see
if the command
ESP plus 0X1C
belongs to the first block,
and the second command
EBP plus C
belongs to the third block,
then we don't need
to do the hypothesis test.
We can easily know
that these two commands
are not the same name.
These two indexes
are not the same name.
Because they point
to different memory areas.
If they have
this kind of ability,
if they have
this kind of ability,
then we don't need
a lot of hypothesis tests.
So the technology
we take is
first of all,
we divide the memory
and then we use
a deep neural network
as a recurrent neural network
to learn
about this command
and then map it.
In this way,
we can do
more deep learning
before we execute
each command.
We can predict
the memory area
for each command.
With this kind of ability,
we don't need
to do
this kind of
hypothesis test anymore.
So here,
I don't want to discuss
more details
about the details of AI.
But I want to share
with you that
after we have
this tool,
before and after,
before we have
AI technology
and before we don't have
AI technology,
what kind of
performance
does it have?
I have a demo here.
I hope you can
play it for me.
OK.
Here it is.
On that screen
and on this screen.
You can see
there are two screens.
One on the left
and one on the right.
You can see
that the program
on the left
is running continuously.
In fact,
it is doing
reverse execution.
On the right,
it is also
doing reverse execution.
On the right window,
there is AI technology
to help.
On the left,
there is no AI technology.
You can see
the right window
is over.
The reverse execution
is over.
But the left window
is still running.
The reverse execution
The total time
it takes
should be
40 seconds,
or more than 30 seconds.
The time on the right
is 17 seconds.
You can see
that with AI technology,
our entire program
is not needed
for a long time
when we are
We can find
the specific
root cause
in a short period
This tool
should have been
released.
You can search
for this name
in GitHub.
You can find it
in DPVSE.
There are a lot of bugs.
If you are interested,
we hope
you can help us
to maintain this code.
Currently,
we are still
doing internal testing.
We hope
this tool
can help us
to save as much time
as possible
OK.
Finally,
I will summarize
our speech.
I believe
everyone
should have
received this information
through this speech.
If you want
to restore
every command
in the memory,
it is actually
a very difficult thing.
However,
it is very helpful
for memory detection
and debug.
And reverse execution
can really
help us
to find
the basic cause
of a software failure.
And using AI technology
including
the technology
of program analysis
is very helpful
for reverse execution.
And in the future,
tools like this
may help
programmers
to find
the basic cause
of program failure
OK.
Thank you very much.
So,
I just talked about
two systems.
So,
the code of the first system
can be downloaded
through this place.
And the code of the second system
should be searched
on GitHub first.
It should be
downloaded first.
OK.
Thank you very much.
Thank you.
If you have any questions,
you can continue to discuss.
Thank you.
there is a question.
OK.
Hello.
Actually,
what you said just now
is that
when improving efficiency
is added machine learning.
So,
the accuracy
before and after
have you measured?
That is,
has the accuracy
after adding machine learning
decreased?
Oh,
the accuracy,
right?
Yes.
The depth of the neural network
is indeed
a problem of accuracy.
Because when you do
memory area judgment,
if you have
1% error,
you may
propagate
this error.
That is,
spread it out.
At that time,
we adjusted
the neural network
to the test data level.
It can be adjusted
to 99% or more.
We ran it.
Indeed,
to be honest,
there is a problem.
But
the situation
is very rare.
Because,
most of the situations
are not transparent.
So,
even when
this error is judged,
it will not
really spread.
So,
in a real environment,
although we will make mistakes,
in fact,
there is not much impact
on analysis.
OK.
OK.
Then,
another
small question
is that
this
training model
of machine learning
referring to
using
one,
for example,
many CRUSH
or many normal
training models.
Is it
a unified
and
more universal
model?
Or,
for each program,
we have to train
a model separately?
What we are doing now
is
the training
for offline training.
For machine learning,
this model
is offline training.
We have used
more than
1,000 programs.
Of course,
there are many
instructions.
But
I don't remember
the exact number.
So, I can't give
the exact number.
But,
it must be
one instruction.
Do offline learning
and then
deploy.
But,
we did consider
in the future,
for example,
through reinforcement learning,
to enhance learning methods
to improve
this kind of
computing ability
and make my model
more accurate.
In the online process,
we can continue
to train this model
to make it better.
This is possible.
But,
now,
it is offline model.
So,
the same model
is used in
various programs.
Many different programs
are used in
the same model.
Sorry,
I didn't hear you.
Is it
different types
or
different programs
are used
in
the same
model
machine learning
program?
Yes.
At the moment,
the data
used in
the training model
is completely
from the program
in the final test.
So,
the data used in
in the process
of running the program,
there is such a situation.
You can't guarantee
that there is no data
in your training data
and the commands
in your final test data
do not match.
This cannot be guaranteed
because
every program
will have
this kind of
library call.
When there is this kind of
library call,
all command series
are the same.
But,
overall,
there is a big
difference.
OK.
OK.
OK.
OK.
Thank you.
OK.
Any other questions?
Yes.
Yes.
Another question is
that
when you do this,
actually,
you are assuming
that
it exists
in
one-to-one
mapping
when it exists
in
one-to-one
mapping.
So,
it can be reversed.
Is it the
and command
to do
a reverse
tracing,
right?
But,
actually,
you can imagine
the entire
execution
flow
as a function,
as a
flow,
an input
and output.
And,
actually,
I mean,
you are assuming
that
if this function
is valid,
if the entire
flow is valid,
then it must be
a one-to-one
mapping.
It is
one-to-one
mapping.
You mean
the one-to-one
No.
I mean
I am talking about
a more
meta-level,
a more abstract
level.
I am explaining
from a mathematical
perspective.
That is to say,
the entire
formula
is a one-to-one
mapping.
I may not
understand
it too well.
The sound
is not good,
so I can't hear it well.
Never mind.
We can
talk about it
later.
Sorry.
Have you ever
parallelized
the whole
the entire
process?
Because I see
that,
I mean,
it's a binary tree,
basically.
I still
don't understand
it.
I can
get closer
to you.
I can
hear you.
You say
that
it is
actually
a binary tree,
right?
Yes.
It is a two-dimensional
tree.
I just want to say that
because of the division
of each tree,
you are actually
doing a depth search,
which is a search
with a priority
Yes.
It's convenient.
And then,
in fact,
each convenient track
is very independent.
Yes.
Under this independent
situation,
I think it can be
parallelized.
Have you ever
tried to parallelize it?
Yes.
I understand.
Because if
the data center
is too big,
you can do it
very quickly.
We are doing
that test.
That is,
when we do
the assumption test,
we really
put it
because
you have more
indicators,
more transparent indicators,
then your tree is deeper.
And then, in fact,
it can be parallelized
and it is the same as
the function execution.
The function execution
can be parallelized.
This step can be parallelized,
but the cost
is also very high.
Of course,
if you have enough machines,
you will be
much faster.
But in the laboratory environment,
we have not yet
done this work,
but it is feasible.
Thank you.
Is there anything else?
Okay,
if there is a question,
we can discuss it
offline.
Thank you very much.
Thank you,
